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BESCHREIBUNG 

Verfahren zur kompakten Darstellung von 
Informationspaketen und deren Speicherung oder Ubertragung 

Gegenstand der Erfindung 

Die vorliegende Erfindung beschreibt ein Verfahren zur 
kompakten Darstellung von Informationspaketen, insbesondere 
von Java-Ob jekten, zur Speicherung auf einem Speichermedium 
mit begrenztem Speicherplatz , insbesondere einer Chipkarte, 
oder zur Ubertragung iiber ein Kanal mit begrenzter 
Bandbreite . 

Stand der Technik 

Speichern von Objekten ist ein wesentliches Thema bei der 
ob jektorientierten Sof tware-Entwicklung . Ein Objekt stellt 
eine nach auflen abgeschlossene Programmeinheit dar, die 
intern durch eine Reihe von lokalen Variablen in ihren 
Eigenschaf ten (Attributen) festgelegt ist. Der Inhalt dieser 
lokalen Variablen legt den Zustand eines Objekts aufierhalb 
des Objekts sind jedoch weder die lokalen Variablen noch ihr 
Inhalt sichtbar. Der Zustand eines Objekts kann 
ausschliefllich durch Ausfuhren eines seiner lokalen 
Unterprogramme verandert werden. Diese Unterprogramme werden 
auch Methoden genannt. Zur Ausfuhrung .einer Methode wird ein 
Objekt von einem anderen Objekt auf gef ordert , indem das 
auffordernde Objekt eine entsprechende Nachricht schickt. 
Das angesprochene Objekt wird, sofern es die Botschaft 
versteht, die entsprechende Methode (lokales Unterprogramm) 
zur Ausfuhrung bringen. Ob jektspeicherung beinhaltet das 
Ablegen von sowohl den Attributen, als auch von dem Zustand 
in denen sich Methoden/Algorithmen befinden, damit diese 
nach der Wiederherstellung des Objektes nahtlos fortgesetzt 
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werden konnen. Persistence, CORBA, ORB sind hierbei gangige 
Schlagworte . 

Fiir Chipkarten existiert keine diesbeziigliche Losung. 
Ublicherweise werden Informationen auf Chipkarten in 
traditionellen Dateistrukturen abgelegt. Fiir die 
Anwendungsdaten der Host-Anwendung stehen auf der Chipkarte 
verschiedene einfache Dateitypen sowie Dateiverzeichnisse 
zur Verfugung. Daten zwischen Host und Karte werden iiber 
einzelne Bef ehlssequenzen (APDUs), denen die Daten in Form 
von Bytes angehangt werden, ausgetauscht . Diese 
dateiorientierten Karten haben heute die groflte Verbreitung. 

Eine gebrauchliche Methode von Java, Ob jektzustande zu 
speichern, ist die Ob jektserialisierung . Serialisierung 
beinhaltet, dass ein beliebiges Objekt in eine Sequenz von 
Bytes umgewandelt wird, die das Objekt und seinen momentanen 
Zustand reprasentiert. Dazu werden alle Attribute, deren 
Name sowie alle weiteren Objekte, auf die das Objekte 
ref erenziert , gespeichert. Mit diesen Informationen kann das 
Objekt unverandert wiederhergestellt werden. Die 
Wiederherstellung verlauft analog: Das Objekt, sowie alle 
anderen Objekte auf die das Objekt ref erenziert , wird 
instanziert und mit den von den Chipkarten gelesenen Daten 
initialisiert . Der Byte-Array, der das Objekt reprasentiert, 
kann sowohl auf JavaCards als auch auf gewohnlichen 
dateiorientierten Karten problemlos gespeichert werden. 

Nachteile Stand der Technik 

Die bisher bekannten Verfahren zur Serialisierung und 
Speicherung von Objekten wurden fiir leistungsf ahige Rechner 
konzipiert. Aufgrund ihres zu hohen Speicherbedarf s sind sie 
fiir das Ablegen von Objekten auf Chipkarten Oder 
Speichermedien mit geringem Speicherplatz ungeeignet oder es 
konnen nur sehr kleine Objekte in serialisierter Form auf 
Chipkarten abgespeichert werden. Bei der Java Object 
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Serialization werden zum Beispiel selbst fur kleine Objekte 
mit wenigen Attributen mehrere hundert Bytes benotigt. 

Es ist daher Aufgabe der vorliegenden Erfindung, ein 
Verfahren bereitzustellen, urn Inf ormationspakete in einer 
einfachen und schnellen Weise in einer sehr kompakten Form 
auf einem Speichermedium mit begrenztem Speicherplatz 
ablegen zu konnen oder iiber einen Ubertragungskanal mit 
geringer Bandbreite iibertragen zu konnen, so dass das 
Inf ormationspaket auf der Empf angerseite wiederhergestellt 
werden kann. 

Diese Aufgabe wird durch die Merkmale in Anspruch 1 Oder 2 
gelost. Weitere vorteilhafte Ausf uhrungsf ormen sind in den 
Unteranspriichen niedergelegt . 

Das erf inderische Verfahren ermoglicht die kompakte 
Darstellung komplexer Inf ormationspakte (wie beispielsweise 
von Objekten im Sinne der 00 Programmierung ) ohne das die 
Inf ormationspakete in einzelne Bestandteile (wie Attribute) 
zerlegt und einzeln optimiert werden muss. 

Das Inf ormationspaket wird als Ganzes (in einer "Black-Box") 
speicherplatzoptimiert abgebildet, so dass sie auf 
Speichermedien, wie zum Beispiel Chipkarten, abgelegt und zu 
einem beliebigen Zeitpunkt auf einem beliebigen System 
unverandert wiederhergestellt werden kann. 
Die Wiedeherstellung erfolgt durch analoge, jedoch 
umgekehrte Anwendung des Algorithmus, wiederum in einer 
Black-Box. 

Das Inf ormationspaket braucht nicht anwendungsf allspezif isch 
und kontextspezif isch analysiert und in einzelne 
Inf ormationen zerlegt werden. 

Der Algorithmus wird auf das Inf ormationspaket als Ganzes 
angewendet - ist anwendungsunabhangig (wenn die Stufe 3 
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angewendet wird, benotigt sie lediglich das zu verwendende 
Worterbuch) - 

Die kompakte Darstellung enthalt alle Inf ormationen in sich, 
um an anderer Stelle unverandert wiederhergestellt zu 
werden . 

Bei der Wiederherstellung des Inf ormationspakets sind keine 
weitere Inf ormationen - aufler dem kompakten 
Inf ormationspaket selbst - notwendig, um es wieder 
herzustellen (ggf . aufter dem Worterbuch, falls Stufe 3 
angewendet wird) . 

Die vorliegende Erfindung wird anhand eines bevorzugten 
Ausf iihrungsbeispiels im Zusammenhang mit FIG. 1 naher 
erlautert . 

Inf ormationspakete im Sinne der vorliegenden Erfindung sind 
beispielsweise : 

1. ) Objekte im Sinne der ob jektorientierten Programmierung 
(z.B. objektorientierte Programmiersprache Java, C++) 

z.B. in Java Programm 
public Object Ticket { 

public String departure = "Stuttgart"; 
public String destination = "Frankfurt"; 
public Ticket(); /Constructor*/ 

}; 

2. ) Datenstrukturen (z.B* klassische Programmiersprache C) 

z.B. in C-Programm 

structure Ticket { 

String departure = "Stuttgart"; 

String destination = "Frankfurt 11 ; 

} 

3. ) Semantische Beschreibungen von Inf ormationen (z.B. 

HTML, XML, Scripte) 
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z.B. in einer f iktiven( I ) Script-Sprache : 
<TICKET><STRING><DEPARTURE> 11 Stuttgart " <STRING>< DESTINATION > " 
Frankfurt" 

Die Inf ormationspakete bestehen aus Meta-Daten und 
Datenelementen . Meta-Daten sind diejenigen Daten, die zur 
Beschreibung der Datenelemente (z.B. Namen und Typ eines 
Datenelements ) erforderlich sind. Datenelemente sind die 
eigentlichen Nutzdaten . 

Speichermedien im Sinne der vorliegenden Erfindung sind 
beispielsweise : 

- Festplatten, Chipkarten, Disketten, u.a. Medien die dazu 

dienen den aktuellen Zustand der betrachteten 

Inf ormationseinheit zwischenzuspeichern, um dieselbe 

Inf ormationspakete zu einem anderen Zeitpunkt und in einem 

anderen System in unverandertem Zustand wiederherzustellen . 

Das vorliegende er f inderische Verfahren zur kompakten 
Darstellung von Inf ormationspaketen wird anhand der 
erf inderischen Verf ahrensschritte 1-4 in Verbindung mit FIG. 
1 dargestellt. Verf ahrensschritte 3-4 stellen besondere 
Ausf iihrungsf ormen der erf inderischen Methode dar, um den 
Komprimierungsf aktor zu erhohen. 

Das Serialisieren im Sinne der nachf olgenden Erfindung 
bedeutet, 1) dass die Meta-Daten und Datenelemente zu einer 
Dateneinheit ( Inf ormationspaket ) zusammengef iihrt werden oder 
2) dass nur die Datenelemente in einer Sequenz dargestellt 
werden, wobei der Empf anger die Zuordnung zwischen Meta- 
Daten und Datenelement durchf iihrt. Im nachf olgenden wird vom 
Serialisierungsverf ahren nach 1) ausgegangen. 

1. Zusammenf iihren von Meta-Daten mit Datenelementen zu einem 
Inf ormationspaket in einer Representation, die alle fur die 
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Wiederherstellung der Information notwendigen Angaben 
enthalt- Zum Beispiel sind Meta-Daten 
Objektname, Objektversion, Objekttyp, Attribute, 
Attributtypen und aktuelle Attributewerte . Fiir das Java 
Objekt "Ticket" miissen gespeichert werden: 

Objekt: Es ist ein Objekt vom Typ " java . lang . Ob ject " mit dem 
Namen "Ticket" (ggf. mit einer Versionsangabe) . 
Das Objekt hat folgende Attribute: 

Attributl: Attribut "departure" vom Typ " java . lang . String" 
mit aktuellem Wert "Stuttgart" 

Attribut2 : Attribut "destination" vom Typ " java . lang . String" 
mit aktuellem Wert "Frankfurt" 

2. In der Representation der Inf ormationspakete werden die 
darin verwendeten Kennungen (Namens-und Typkennungen) , wie 
z.B. java • lang . String, java . lang . Ob ject , etc., durch 
spezielle, definierte Identif ikatoren oder Stellvertreter 
(z.B. tags gemafl TLV-Codierung nach ISO 8825 BER-TLV) 
dargestellt. Damit erhalt man eine Darstellung, die 
beispielweise fur den menschlicher Leser wie folgt 
aufbereitet dargestellt werden kann: 

[ ( 1, l,true) 321] 
( 

[( 15, 1, false) 21] ( "tests . compress . Ticket" ) 

[(7,2, true) 294] 

( 

[ (18,1, false) 13] ( "departure" ) 

[(8,2, false) 1] ( 'Ol' ) 

[ (16,1, false) 9] ( "Stuttgart" ) 

[ (18,1, false) 15] ( "destination" ) 

[(8, 2, false) 1] ( 'Ol' ) 

[ (16,1, false) 10] ( "Frankfurt" ) 

) 

) 
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Dabei bedeuten die Angaben folgendes: 

[ ( tag- Identif ikator, class , constructed flag) length] ( Inhalt ) 

tag-Identif ikator dient zur Unterscheidung verschiedener 
tags, class dient zur Unterscheidung verschiedener Klassen 
von tags und constructed flag zeigt an, ob dem tag einfache 
Nutzdaten folgen oder wiederum weitere tags mit zugehorigen 
Nutzdaten . 

Length umfaflt die Anzahl Bytes der folgenden Nutzdaten, 
Inhalt bedeutet entweder zugehorige Nutzdaten oder weitere 
tags . 

3- In einer besonderen Ausf uhrungsf orm der vorliegenden 
Erfindung wird folgender zusatzlicher Ver f ahrensschritt 
angewandt : 

Der vorhergehende Schritt 2 wird wiederholt, wobei jedoch 
nicht anwendungsunabhangige , sondern anwendungsabhangige 
Kennungen durch Identif ikatoren ( Stellvertreter ) dargestellt 
werden. Vorzugsweise ist ein Worterbuch notwendig, das fur 
einen speziellen Anwendungskontext , spezielle 
Identif ikatoren festlegt (z.B. fur Reiseanwendungen konnte 
Tag xy fiir "departure" und Tag yz fur "destination" stehen) . 
Damit kann eine weitere Reduktion des fiir die Representation 
des Inf ormationspakets notwendigen Speichers erzielt werden. 
Damit erhalt man eine Darstellung, die beispielweise wie 
folgt aussieht: 

[ ( 1, l,true) 321] 
( 

[( 15, 1, false) 21] ( "tests . compress . Ticket " ) 

[(7,2, true) 2 94] 

( 

[ (26,1, false) 9] ( "Stuttgart" ) 
[ (26,1, false) 10] ( "Frankfurt" ) 

) 
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) 

4. In einer weiteren besonderen Ausf iihrungsf orm wird 
folgender zusatzliche Verf ahrensschritt angewandt: 

Die erzielte Darstellung wird mit Hilfe gangiger 
Komprimierungsalgorithmen, z.B. ZLIB, noch einmal 
komprimiert . 

Insgesamt werden durch die Schritte 1-4 eine kompakte 
Representation der Inf ormationspakete erzielt, die ca. 30% 
weniger Speicherplatz in Anspruch nimmt, als eine 
gewohnliche Serialisierung mit bestmoglicher Komprimierung 
durch Komprimierungsalgorithmen wie ZLIB. 

Trotz der Komprimierung des Inf ormationspakets sind alle 
Inf ormationen enthalten, urn das Paket an anderer Stelle zu 
einem anderen Zeitpunkt unverandert wiederherstellen zu 
konnen. 

Das vorliegende erf inderische Verfahren wird anhand von 
Java-Ob jekten dargestellt. 

Anwendungsbeispiel : 

Im nachf olgenden Ausf iihrungsbeispiel wird die Java-Object- 
Serialisierung durch ein Serialisierungsverf ahren mit TLV 
(Tag Length Value) Strukturen ersetzt. Bei der Speicherung 
von Objekten auf einer Chipkarte mit Hilfe von TLV 
Strukturen wird durch die Vorverarbeitung der ..tags" 
Speicherplatz eingespart . 

Die Einsparung von Speicherplatz erfolgt in vier Schritten: 

1. Erzeugung der Ob jektdarstellung ( Zusammenf iihren von Meta- 
Daten und Datenelemente , Bilden einer Sequenz) 
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2. Codierung der anwendungsunabhangigen Kennungen in tags, 
z.B. fiir Objekte, Attribute, Namen, Klassen, . . . 

3. Codierung von anwendungsabhangigen Kennungen in tags 

4. Zusatzliche Komprimierung 
Vorgehensweise : 

Ein Objekt wird auf der Chipkarte wie folgt dargestellt: 

- Name des Objekts 

- Typ des Objekts (string, integer, object) 

- Version 

- Attribute des Objekts (Attribute und Werte der Attribute 
konnen selbst wieder Objekte sein) . 

Beispiel: 

In folgendem Beispiel konnen alle grofl geschriebenen Worter 
durch „tags" dargestellt werden. Zu jedem „tag" gehort ein 
Wert und die Lange dieses Werts . 

NAME ( 11 BC 11 ) 
TYPE (OBJECT) 
OBJECT ( 

NAME ( "com. ibm . bus inesscard . BusinessCard" ) 
TYP (object) 
VERSION ("1. 1") 
ATTRIBUTE ( 

NAME ( "Name" ) 

TYPE (STRING) 

VALUE ( "Mustermann" ) 

) 

ATTRIBUTE ( 

NAME ("Address") 



(9 

GE 999 04 

- 10 - 



TYPE (OBJECT) 
OBJECT ( 

NAME ( "com. ibm. business .Address" ) 
VERSION ("1.0") 

ATTRIBUTE ( NAME ( " Street " ) TYPE ( STRING ) 
VALUE ( "Schoenaicher Str. 220")) 
ATTRIBUTE ( NAME ( "City") TYPE (STRING) 
VALUE ( "Boeblingen" ) ) 

) 

) 

In einer Tabelle, die Bestandteil des erf indeirischen 
Komprimierungsalgorithmus ist, ist die Zuordnung zwischen 
„Identif ikator" ( Stellvertreter ) und einem „tag" abgelegt. 
Die „tags" werden vorzugsweise gemafi BER-TLV bestimmt . 
Als „tags" werden vorzugsweise diejenigen Identif ikatoren 
definiert, die anwendungsunabhangig sind. 
In der nachf olgenden Tabelle ist eine beispielhaf te 



Zuordnung 


abgebildet 








Tags 
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ID 


Constructed 


Enc 


OBJECT 
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true 
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CLASS 
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false 
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VERSION 
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NAME 
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false 
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VALUE 
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false 
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ID 
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STRING 
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OBJECT 
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Fur das Beispiel: 



A0(tag-hex fur object) 
xx 

84 (tag-hex fur name) 32 (Lange in Byte)" 

com. ibm. businesscard . BusinessCard" 

82 (tag-hex fur version) 03(Lange in Byte) 

"1.0" 

A3 (tag-hex fur Attribute ) 35 ( Lange des 

Attributs in Byte ) Wert : 84 , 85 , 86 

84 (tag-hex fur name) 04 ( Lange des name) ..Name" 

(Wert) 

85 (tag-hex fur Typ) 01 (Lange des Typs) 
Wert : 1 

86 (tag -hex fur Value) 10 (Lange des 

Values ) Wert : "Mustermann" 

A3 (tag-hex fur Attribute ) 35 ( Lange des 

Attributs in Byte ) Wert : 84 , 85 , 86 

84 (tag-hex fur name) 04 ( Lange des name) Wert 

„ Address,, 

85 (tag-hex fur Typ) 01 (Lange des Typs) 
Wert: 2 



Urn die Komprimierung noch zusatzlich zu erhohen, kann 
folgende zweite Komprimierungsphase angewendet werden: 

Das nach dem oben beschriebenen Verfahren erzielte Ergebnis 
wird anschlieflend nach vordef inierten, anwendungsabhangigen 
Namens-und Typkennungen fur Objekte durchsucht. Fiir diesen 
Verf ahrensschritt stehen spezielle „tags" zur Verfiigung, mit 
denen diese Kennungen platzsparend dargestellt werden 
konnen. Dadurch wird eine weitere Komprimierung erreicht. 
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Die Zuordnung zwischen diesen anwendungsabhangigen Kennungen 
und den „tags", durch den diese dargestellt werden konnen, 
mufl natiirlich alien Beteiligten, die Informationen lesen 
oder schreiben wollen, bekannt sein. Denkbar ist es, 
verschiedene Zuordnungstabellen fur verschiedene 
Anwendungskontexte zu definieren. Es werden je nach Kontext 
ofter benotigte Strukturen und Typen festgelegt, urn 
redundante Inf ormationsspeicherung zu vermeiden. 
Beispielsweise konnte ein Anwendungskontext „Travel" , tags 
wie Sitzplatz, Zielort, Abf ahrtszeit , etc. definieren. 

Aufbau, Definition und Lange von () tags M sind in den Normen 
ISO/IEC 7816, bzw. 8825 festgelegt. Fur diese neue 
Anwendungsmoglichkeit von TLV Strukturen ist es evtl . 
erf orderlich , die maximale Lange der „tags" zu erhohen. 
Das folgende Beispiel soli diese zweite Komprimierungsstuf e 
erlautern : 

Der Name „com , ibm . businesscard . BusinessCard" ist in dem 
Anwendungskontext definiert und kann wie folgt verkiirzt 
dargestellt werden : 

AO (tag-hex fur object) 
xx 

84 (tag-hex fur name) 32 (Lange in Byte) BF 
82 (tag-hex fur version) 03(Lange in Byte) "1.0" 
A3 (tag-hex fur Attribute ) 35 (Lange des Attributs in 
Byte ) Wert : 84 , 85 , 86 

84 (tag-hex fur name) 04 ( Lange des name) „Name" (Wert) 
85 (tag-hex fur Typ) 01 (Lange des Typs) Wert:l 
86 (tag -hex fur Value) 10 (Lange des 
Values ) Wert : "Mustermann" 

A3 (tag-hex fur Attribute ) 35 ( Lange des Attributs 
inByte)Wert : 84 , 85 , 86 

84 (tag-hex fur name) 04 ( Lange des name) Wert „Address„ 
85 (tag-hex fur Typ) 01 (Lange des Typs) Wert : 2 
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Tag 



Klasse 



ID 



Constructed 



Type Class 



BF 



2 



100 



true 



Name 



com.ibm. . .BusinessCard 



Die Zuordnung zwischen tag und Identif ikator mufl dem 

Empf anger bekannt sein oder muft mitiibertragen werden (z.B. 



die Tupel der Form <Tag,Klasse, ID, Constructed, Type, Class> ) 
Evaluierung des Methode 

Zur Abschatzung des Potentials des beschriebenen 
erf inderischen Verfahrens wurden verschiedene Objekte 
entsprechend des erf inderischen Verfahrens komprimiert und 
die dabei erreichte Komprimierung bewertet . Hierbei wurden 
insbesondere Ergebnisse, die mit Hilfe anderer, bekannter 
Komprimierungsalgorithmen erreicht wurden, zum Vergleich 
herangezogen . 

Beispiel 1: 

Nachf olgendes Objekt beschreibt ein Flugticket: 

public class Ticket extends Object implements Serializable 
{ 

public String passengerName ="Hans Mustermann"; 

public String passengerAddress = "Schoenaicher Strasse 220"; 

public String passengerCity = "71032 Boeblingen" ; 

public String departureCity= "Stuttgart"; 

public String destinationCity= "Whitehorse" ; 

public Integer f lightNumber= new Integer ( 478 ) ; 

public String airline= "LH"; 

public String date= M 24. 12.99"; 
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public String departureTime= "11: 00"; 

public Integer ticketPrice= new Integer ( 1200 ) ; 

public Integer status = new Integer(l) ; 

// Default Constructor 
public Ticket ( ) { 
} 

} 

Beispiel 2: 

Dieses Flugticket enthalt die Passagierinf ormationen in einem 
gesonderten Objekt. Die Methodik mufi also auf verschachtelte 
Objekte angewendet werden, was eine Rekursion erfordert. 

public class Ticket2 extends Object implements Serializable 
{ 

public Passenger passenger 

= new Passenger ("Hans Mustermann" , 

"Schoenaicher Strasse 220", 

"71032 Boeblingen" ) ; 
public String departureCity= "Stuttgart"; 
public String destinationCity= "Whitehorse" ; 
public Integer f lightNumber= new Integer ( 478 ) ; 
public String airline= "LH"; 
public String date= "24.12.99"; 
public String departureTime= "11:00"; 
public Integer ticketPrice= new Integer ( 1200 ) ; 
public Integer status = new Integer(l) ; 

// Default Constructor 
public Ticket2 ( ) { 
} 



public class Passenger extends Object implements Serializable 
{ 
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public String passengerName = ,! Hans Mustermann"; 

public String passengerAddress = f, Schoenaicher Strasse 220"; 

public String passengerCity ="71032 Boeblingen 1 ' ; 

// Default Constructor 
public Passenger ( ) { 

} 

} 

Bewertung der erreichten Komprimierung: 

Die nachfolgende Tabelle zeigt den fur die Darstellung der 
Beispielsob jekte benotigten Speicherplatz bei 
konventioneller Serialisierung und bei Anwendung der ersten 
Stufe der hier vorgestellten kompakten Darstellung. Es wurde 
jeweils durch Anwendung des "ZLib Data Compression 
Algorithm" mit der Einstellung "Best Compression" noch eine 
zusatzliche Verbesserung des Ergebnisses erreicht. 



Die Anwendung der zweiten Stufe der hier vorgestellten 
Methode wiirde eine weitere Verbesserung erzielen, wurde 
jedoch nicht in diese Evaluierung einbezogen. 





Konvent ionelle 


Konvent ionel le 


Kompakte 


Kompakte 




Ob jekt seriali- 


Ob jekt seriali- 


Darstellung 


Darstellung 




sierung in 


sierung in 


der Ob jekte 


der Ob jekte 
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Algorithm) 
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AlaorithnO 


Beisoiel 1 


642 Bvte 


35 3Bvte 


325 Bvte 


245 


Beispiel 2 


72 5 Bvte 


392Bvte 


374 Bvte 


268 



In Beispiel 1 wird eine Verdichtung urn 31 % gegeniiber dem 
mit ZLib komprimierten serialisiertem Objekt erzielt. In 
Beispiel 2 betragt die Verdichtung 32 %. Verschiedene 
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weitere untersuchte Objekte ergaben Werte zwischen 16 % und 
40%. 

Die Methode zielt im Wesentlichen darauf ab, die Meta-Daten 
einer Ob jektreprasentation zu minimieren. Das bedeutet, daft 
der Komprimierungsf aktor steigt, je kiirzer die Datenlangen 
der einzelnen Attribute eines Objektes sind. Bei sehr grofien 
Dateninhalten je Attribut, ist der Nutzen etwas geringer. 

Vorteile der Losung 

Durch das Ersetzen der Java Ob jektserialisierung durch das 
beschriebene Verfahren konnen Objekte kompakt und 
platzsparend auf Chipkarten abgespeichert werden. Dies 
vereinfacht zum einen, den Programmieraufwand, urn 
Objektdaten auf einer Chipkarte zu speichern und auszulesen, 
zum anderen erhalt man durch Anwendung dieses Verfahrens 
Ob j ektreprasentat ionen , die sehr klein sind. Es wurde eine 
Reduzierung des Speicherplatzes urn 25- 50 % gegeniiber der 
klassichen Ob jektserialisierung f estgestellt . 
Die zweite Stufe des vorgestellten Verfahrens erzielt eine 
zusatzliche Komprimierung . Sie setzt jedoch eine 
branchenspezif ische, einheitliche Definition von 
Anwendungsattributen voraus . 

So konnten Anwendungen . der Tourismusbranche , fur ihren 
Kontext eine Reihe von Attributen wie Reisepreis, 
Abflugdatum, Passagiername , etc. durch standardisierte „tags 
ersetzen . 

Ein weiterer Vorteil dieser Losung ist der Briickenschlag 
zwischen der Methodik der Ob jektserialisierung und der 
Benutzung des TLV Verfahrens . 

Im nachf olgenden wird eine konkrete Implementierung der 
vorliegenden Erfindung dargestellt. 
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* serialize 

* Serializing the state of a given object, using common Java 
methods 

*************************************^ 
public bytef] serialize (Object object) 
{ 

byte[] result = null; 
try { 

// create a byte array and a output stream 
ByteArrayOutputStream buffer = new 
ByteArrayOutputStream( ) ; 

//FileOutputStream buffer = new FileOutputStream( " test " ) ; 
Ob jectOutputStream out=new Ob jectOutputStream ( buf f er ) ; 

// write to stream 

out .writeObject (object) ; 

out . close ( ) ; 

// result 

result = buf f er . toByteArray ( ) ; 

catch (Exception e) { 
System. out . println( "Shit happens" ) ; 

return result; 




} 
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/********************* *********************** **************** 

* restore 

* Restoring a serialized Jav Object, using common Java-methods 
*************************************************************/ 

public Object restore ( byte [ ] data){ 
Object object = null; 
try { 

// create a byte array input stream 
ByteArraylnputStream buffer = new 
ByteArray InputStream ( data ) ; 

Ob jectlnputStream in = new Ob jectlnputstream( buf f er ) ; 

// read from stream 
object = in . readOb ject ( ) ; 
in . close ( ) ; 

} catch (Exception ex) { 

System. out ,println( "Shit happens" ) ; 

} 

return object; 

} 

/************************************************************ 

* simpleZip 

* Compressing bytes using the common ZLIB Algorithmus with 

■ 

option BEST_COMPRESSION 
********************* ******* *********************************/ 

public byte[] simpleZip(byte[ ] data) { 

byte[] result = null; 

Def later def later = new Def later (Def later . BEST_COMPRESSION, 
true) ; 

def later . set Input ( data , 0 , data • length ) ; 
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def later . f inish( ) ; 

byte[] buffer = new byte [5000]; 

int length = def later .def late(buffer) ; 

result = new byte [ length] ; 

System. arraycopy (buff er, 0, result, 0, length); 
return result; 

} 

/************************************************************* 
* simpleUnZip 

j£ * Unzipping compressed bytes using the ZLIB Algorithmus 

****************** *******************************************/ 

public byte[] simpleUnZip(byte[ ] data) { 
byte[] result = null; 
try { 

Inflater inflater = new Inf later ( true ) ; 
inf later . set Input ( data , 0 / data . length ) ; 

byte[] buffer = new byte[5000]; 

int length = inf later . inf late(buffer) ; 

result = new byte [ length ] ; 

System. arraycopy (buff er, 0, result, 0, length); 
} catch (Exception ex) { 

System. out .println( "Shit happens" ) ; 

} 



return result ; 

} 
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specialSerialize 

Serializing a object using TLV structure to replace 
redundant information 
************* ************************************* **********/ 

public TLV specialSerialize(Object object) { 
TLV result = null; 

System. out ,println( "\nspecial serialize . . . \n M ) ; 

// just a simplified implementation without nested classes! 
try { 

// 1.) create the attributeTLV Containing the attributes 
TLV attributeTLV = null; 

Field[ ] f ields=ob ject . getClass ( ) .getFields( ) ; 

for (int i=0; i<fields . length; i++) 
{ 

// get field name 

String fieldName = f ields [ i ] . getName ( ) ; 

System . out . print In ( "optimized serialization of field 
"+f ieldName) ; 

TLV nameTLV = new TLV ( TAG_NAME , fieldName . getBytes () ) ; 
if ( attributeTLV==null ) 

attributeTLV = new TLV ( TAG_ATTRIBUTE , nameTLV); 
else 

attributeTLV. add ( nameTLV) ; 
// get fieldValue and Type 

Object fieldValue = f ields [ i ]. get ( object ) ; 
Class fieldType = f ields [ i ]. getType () ; 
TLV typeTLV=null; 
TLV valueTLV = null; 



- 21 - 



GE 999 046 



// Strings . . . 
if 

( f ieldType . i s Ass ignableFrom( Class . f orName ( M java . lang . St 
ring"))) { 

typeTLV = new TLV ( TAG_TYPE , TYPE_STRING) ; 
valueTLV = new TLV ( TAG_VALUE , 
( ( String) f ieldValue) .getBytes ( ) ) ; 
} 

else 
{ 

// Integers . . . 

if ( f ieldType . isAssignableFrom(Class . f orName( "java . la 
ng . Integer" ) ) ) { 

typeTLV = new TLV ( TAG_TYPE , TYPE_INTEGER ) ; 
valueTLV = new TLV ( TAGJVALUE , (( Integer ) f ieldValue 

) . intValue( ) ) ; 

} else { 

// other Objects . . . 

typeTLV = new TLV ( TAG_TYPE , TYPE__OB JECT ) ; 
// o.k. go into recursion . .. 
TLV embeddedOb jectTLV = specialSerialize ( f ieldValue ) ; 
valueTLV = new TLV ( TAG^VALUE, 
embeddedOb jectTLV. toBinary( ) ) ; 

} 

} 

attributeTLV. add (typeTLV) ; 
attributeTLV. add (valueTLV) ; 

} 

// 2.) create the Class TLV 
TLV classTLV = new TLV (TAG_CLASS, 
object . getClass ( ) .getName( ) . getBytes ( ) ) ; 
System. out .println( "optimized serialization of class 
"+object . getClass ( ) .getName( ) ) ; 
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// 3.) create the wrapper around the attributes 
TLV objectTLV = new TLV (TAG_OBJECT, classTLV) ; 
// ****tc> DO****TO DO objectTLV. add (vers ionTLV) ; 
objectTLV. add (attributeTLV) ; 

// we've got it now: objectTLV is our specialZipped 
Object ! 

result = objectTLV; 

} catch (Exception ex) { 

System. out .println( "Shit happens" ) ; 
ex.printStackTrace( ) ; 

} 

return result; 

} 

* specialRestore 

* Restoring an object serialized with the method 
specialSerialize( ) 

*********************************** 

public Object specialRestore ( TLV data) { 

Object result = null; 

System. out .println( "\nspecial restore ... \n"); 

try 
{ 

TLV objectTLV = data; 
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// unzip the object itself 

TLV classTLV = ob jectTLV . f indTag ( TAG__CLASS , null); 
Class objectClass = Class . forName ( new StringclassTLV . 

valueAsByteArra 

y<)>>; 

System. out . println ( "restoring Class 
"+ob jectClass . getName( ) ) ; 
result = objectClass . newlnstance ( ) ; 

// restore the version . . . 
// ****to DO**** 

// restore all values of the object 

TLV attributeTLV = ob jectTLV . f indTag ( TAG_ATTRIBUTE , 
null) ; 

// loop through all attributes of the attribute TLV 

TLV lastProccessedNameTLV = null ; 

TLV lastProccessedTypeTLV = null; 

TLV lastProccessedValueTLV = null; 

TLV aNameTLV = null; 

TLV aTypeTLV = null; 

TLV aValueTLV = null; 

do 

{ 

// find the next subTLV in the attributeTLV 
aNameTLV = attributeTLV . f indTag ( TAG_NAME , lastProcce 
ssedNameTLV) ; 

aTypeTLV = attributeTLV . f indTag ( TAG_TYPE , 

lastProccessedTypeTLV) ; 

aValueTLV = attributeTLV. f indTag (TAG^ALUE, 
lastProccessedValueTLV) ; 

if ( ( aNameTLV !=null)&&( aTypeTLV !=null)&&( aValueTLV !=null) ) 
{ 

// restore the field "aName" with the value "aValue" 
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String aName = new String (aNameTLV. valueAsByteArray ( ) ) 
System. out. println( "restoring Field M + aName); 
Field field = objectClass .getField(aName) ; 
int aType = aTypeTLV . valueAsNumber ( ) ; 

if (aType == TYPE_STRING) { 
// STRING. . . 
String aValue = new String 
( aValueTLV. valueAsByteArray ( ) ) ; 
field . set ( result , aValue) ; 
} else { 

if (aType == TYPE_INTEGER ) { 
// INTEGER . . . 
Integer aValue = new Integer 
(aValueTLV. valueAsNumber ( ) ) ; 
field . set ( result , aValue) ; 
} else { 

// OBJECT . . . 

// o.k. go into recursion ... 
Object aValue = specialRestore ( new TLV 
(aValueTLV. valueAsByteArray ( ) ) ) ; 

field . set ( result , aValue) ; 
} // else integer 
} // else string 
} // if TLV's !=null 
lastProccessedNameTLV = aNameTLV; 
lastProccessedTypeTLV = aTypeTLV; 
lastProccessedValueTLV = aValueTLV; 

} while ( (aNameTLV! =null) ) ; 

} catch ( Exception ex) { 

System. out . println( "Shit happens" ) ; 
ex.printStackTrace( ) ; 

} 

return result; 
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PATENTANSPRUCHE 

1. verfahren zum Erzeugen einer kompakten Darstellung eines 
Inf ormationspakets , wobei das Inf ormationspaket 
zuminclest aus Meta-Daten unci dazugehorige Datenelemente 
und/oder Meta-Daten und dazugehorige Inf ormationspakete 
besteht, wobei die Meta-Daten zumindest aus Namens- und 
Typkennungen des Datenelements oder Namens- und 
Typkennungen des Inf ormationspakets bestehen, 
gekennzeichnet durch folgende Schritte: 

a) Anordnen der Inf ormationspakete in einer Sequenz 

b) Durchsuchen der Meta-Daten nach definierten 
anwendungsunabhangigen Namens- und Typenkennungen 
(Kennungen) 

c) Darstellen der nach Schritt b) gefundenen 
Kennungen durch definierte Stellvertreter mit 
geringerem Speicherbedarf . 

2. Verfahren zum Erzeugen einer kompakten Darstellung 
einer Struktur von Meta-Daten und Datenelementen, wobei 
die Zuordnung von Meta-Daten zu Datenelementen oder 
Meta-Daten zu einer Unterstruktur einer Struktur durch 
ein Programm erf olgt , wobei die Meta-Daten zumindest 
aus Namens- und Typkennungen (Kennungen) des 
Datenelements oder Kennung der Unterstruktur der 
Struktur bestehen, gekennzeichnet durch folgende 
Schritte : 

a) Zusammenf iihren von Meta-Daten und zugehorigen 

Datenelementen oder Meta-Daten mit der zugehorigen 
Unterstruktur zu einem Inf ormationspaket 
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b) Anordnen der Inf ormationspakete in einer Sequenz 

c) Durchsuchen der Meta-Daten nach definierten 
anwendungsunabhangigen Kennungen 

d) Darstellen der nach Schritt c) gefundenen 
Kennungen durch definierte Stellvertreter mit 
geringerem Speicherbedarf . 

3. Verfahren nach Anspruch 1 oder 2 gekennzeichnet durch 
folgenden weiteren Schritt: 

e) Speichern des Ergebnisses nach Schritt a-d auf 
einem Speichermedium 

4 . Verfahren nach Anspruch 1 oder 2 gekennzeichnet durch 
folgenden weiteren Schritt: 

e) Ubertragen des Ergebnisses nach Schritt a-d auf 
ein Datenverarbeitungsgerat . 

5. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass 
die Meta-Daten nach Anspruch 3 oder 4 nicht mit 
ubertragen werden, sondern die Zuordnung bei der 
Wiederherstellung durch ein Programm erfolgt. 

6. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass 
das Inf ormationspaket ein Objekt ist, das zumindest 
folgende Datenelemente mit folgenden 
anwendungsunabhangigen Kennungen enthalt: 

Objektname, Objekttyp und Ob jekt-Attribute . 

7. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass 
das Inf ormationspaket ein Objekt ist, das folgende 
Datenelemente mit folgenden anwendungsunabhangigen 
Kennungen enthalt : 
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Objektname, Objekttyp, Ob jektversion unci Objekt- 
Attribute . 

Verfahren nach Anspruch 4 dadurch gekennzeichnet, dass 
das Inf ormationspaket ein Java-Objekt ist. 

Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass 
das Inf ormationspaket ein XML (Extendable Markup 
Language) ist. 

Verfahren nach Anspruch 1 oder 2 dadurch 
gekennzeichnet, dass die anwendungsunabhangigen 
Kennungen Objektname, Objekttyp, Ob jektversion und 
Objekt-Attribute durch definierte Stellvertreter in 
einer TLV-Codierung dargestellt werden. 

Verfahren nach Anspruch 1 oder 2 dadurch 
gekennzeichnet, dass die anwendungsunabhangigen 
Kennungen Objektname, Objekttyp, Ob jektversion und 
Objekt-Attribute durch definierte Stellvertreter in der 
TLV-Codierung nach ISO 8825 Basic Encoding Rules 
dargestellt werden. 

Verfahren nach Anspruch 1 oder 2 dadurch 
gekennzeichnet, da/i das Inf ormationspakt eine 
Datenstruktur ist, die Datenelemente mit folgenden 
anwendungsunabhangigen Kennungen enthalt: 

Name, Typ, Version und Attribute des Datenelements 

Verfahren nach Anspruch 1 oder 2 dadurch 
gekennzeichnet, dafi die Schritte a)-d) durch ein 
Programm durchgefiihrt werden, wobei im Programm eine 
Tabelle zur Zuordnung von anwendungsunabhangigen 
Kennungen mit den zugeordneten Stellvertretern 
enthalten ist . 
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14 • Verf ahren nach Anspruch 1 oder 2 gekennzeichnet durch 
folgende weiteren Schritte: 

aa) Durchsuchen der Meta-Daten nach definierten 
anwendungsabhangigen Kennungen 

bb) Darstellen der nach Schritt aa) gefundenen 

anwendungsabhangigen Kennungen durch definierte 
Stellvertreter mit geringerem Speicherbedarf 

cc) Speichern des Ergebnisses nach Schritt aa)-bb) auf 
einem Speichermedium oder Ubertragen des 
Ergebnisses nach Schritt aa)-bb) auf ein 
Datenverarbeitungsgerat . 

15- Verfahren nach Anspruch 14 dadurch gekennzeichnet, daft 
fur jede Anwendung eine eigene Tabelle mit definierten 
anwendungsabhangigen Kennungen und zugeordneten 
Stellvertreter geladen wird anhand der Verf ahrenschritt 
bb) nach Anspruch 14 erfolgt. 

16. Verfahren nach Anspruch 1 oder 2 dadurch 
gekennzeichnet, dafi die Stellvertreter in Aufbau, 
Definition und Lange durch die Normen ISO/IEC 7816 oder 
8825 festgelegt werden. 

17. Verfahren nach Anspruch 16 dadurch gekennzeichnet, dass 
der Stellvertreter maximal 2 Byte Speicherplatz 
einnimmt . 

18. Verfahren nach Anspruch 16 dadurch gekennzeichnet, dass 
sich der Stellvertreter aus Klasse, constructed flag 
und ID zusammensetzt . 

19. Verfahren nach Anspruch 14 gekennzeichnet durch 
folgenden weiteren Schritt: 
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aaa) 



Anwenden eines gangigen 

Komprimierungsalgorithmus auf das Ergebnis 
nach Schritt aa)-bb) des Anspruchs 14 



bbb) 



Speichern des Ergebnisses nach Schritt aaa) 
auf einem Speichermedium oder Ubertragen des 
Ergebnisses nach Schritt aaa) auf ein 
Datenverarbeitungsgerat . 



20. Verfahren nach Anspruch 19 dadurch gekennzeichnet , dass 
der Komprimierungsalgorithmus der ZLIP- 
Komprimierungsalgorithmus ist . 

21. Verfahren nach Anspruch 1 oder 2 dadurch 
gekennzeichnet, dass das Speichermedium eine Chipkarte 
oder ein mobiler Datentrager ist oder dass der 
Ubertragungskanal eine geringe Bandbreite hat. 

22. Chipkarte enthaltend zumindest einen nichtf liichtigen 
Speicher, dadurch gekennzeichnet, dass das Ergebnis des 
Verfahrens nach Anspruch 1 bis 21 im nichtf liichtigen 
Speicher in einer Datei abgespeichert ist. 

23. Vorrichtung enthaltend zumindest: 

a ) Datenverarbeitungsgerat 

b ) Kommunikat ionsmittel 

c) Chipkarte, wobei iiber das Kommunikationsmittel Daten 
zwischen Datenverarbeitungsgerat und Chipkarte 
austauschbar sind, dadurch gekennzeichnet, dass auf dem 
Datenverarbeitungsgerat ein Programm zur Steuerung 
eines Verfahrens nach Anspruch 1 bis 21 installierbar 
ist und das Ergebnis des Verfahrens nach Anspruch 1 bis 
21 auf der Chipkarte abgespeichert ist. 
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Computerprogrammprodukt, das im internen Speicher eines 
digitalen Rechner gespeichert werden kann, enthaltend 
Teile von Softwarecode zur Ausfuhrung des Verfahrens 
nach Anspruch 1-21, wenn das Produkt auf dem Rechner 
ausgefiihrt wird. 
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ZUSAMMENFASSUNG 



Das erf inderische Verfahren basiert darauf, 
Inf ormationspakte-insbesondere Java -Ob jekte- vor ihrer 
Ubertragung bzw. Speicherung auf einem Speichermedium, in 
serialisierter Form darzustellen, auf anwendungsunabhangige 
Kennungen zu untersuchen und die anwendungsunabhangigen 
Kennungen durch Stellvertreter mit geringerem Speicherbedarf 
darzustellen. In einer weiteren Ausf iihrungsf orm werden auch 
die anwendungsabhangigen Kennungen durch spezielle 
Stellvertreter dargestellt. Das Ergebnis dieses Verfahrens 
ermoglicht die kompakte Darstellung komplexer 
Inf ormationspakte, ohne dass die Inf ormationspakete in 
einzelne Bestandteile zerlegt und einzeln optimiert werden 
miissen . 

Das Inf ormationspaket wird als Ganzes speicherplatzoptimiert 
abgebildet, so dass sie auf Speichermedien, wie zum Beispiel 
Chipkarten, abgelegt und zu einem beliebigen Zeitpunkt auf 
einem beliebigen System unverandert wiederhergestellt werden 
kann . 

Die Wiedeherstellung erfolgt durch analoge, jedoch 
umgekehrte Anwendung des Algorithmus, wiederum in einer 
Black-Box . 

Das Inf ormationspaket braucht nicht anwendungsf allspezif isch 
und kontextspezif isch analysiert und in einzelne 
Inf ormationen zerlegt werden. Durch die Anwendung dieses 
Verfahrens kommt es zu einer ca . 30% Verdichtung der 
Darstellung der Daten eines Inf ormationspakets . 
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